home *** CD-ROM | disk | FTP | other *** search
/ IRIX Installation Tools & Overlays 1999 May / SGI IRIX Installation Tools & Overlays 1999 May - Disc 2.iso / relnotes / pcp_eoe / ch3.z / ch3
Text File  |  1999-04-19  |  24KB  |  578 lines
  1.  
  2.  
  3.  
  4.                                   - 1 -
  5.  
  6.  
  7.  
  8.        3.  _C_h_a_n_g_e_s__a_n_d__A_d_d_i_t_i_o_n_s
  9.  
  10.        The major additions and changes for the basic services and
  11.        tools of the Performance Co-Pilot are described in the
  12.        following sections.  Unless otherwise stated, all changes
  13.        describe PCP 2.0 relative to the prior PCP 1.3 release.
  14.  
  15.        Refer to the reference pages of the individual utilities for
  16.        a complete description of any new functionality.
  17.  
  18.        3.1  _I_n_f_r_a_s_t_r_u_c_t_u_r_e__C_h_a_n_g_e_s
  19.  
  20.        The following changes have been made to the PCP
  21.        infrastructure that affect both collector and monitor
  22.        configurations.
  23.  
  24.          1.  The PCP Performance Metrics Name Space (PMNS) has
  25.              previously been local to the application wishing to
  26.              make reference to PCP metrics by name.  In PCP 2.0 the
  27.              PMNS operations are directed to the host or archive
  28.              that is the source of the desired performance metrics,
  29.              see ppppmmmmnnnnssss(4).
  30.  
  31.              The default name space is now associated with the PCP
  32.              collector host rather than PCP monitor host.  The
  33.              distributed PMNS involves changes to both the PCP
  34.              protocols between client applications and ppppmmmmccccdddd, and
  35.              the internal format of PCP archive files (the
  36.              ppppmmmmllllooooggggggggeeeerrrr(1) utility is able to write PCP archive logs
  37.              in either the old or new formats).
  38.  
  39.          2.  PCP monitor hosts do not require any name space files,
  40.              unless the local PCP client applications need to
  41.              connect to PCP collector hosts that have not yet been
  42.              upgraded to PCP 2.0.  The distributed PMNS is
  43.              implemented by having the name space functions of the
  44.              PCP Performance Metrics Application Programming
  45.              Interface (PMAPI) send and receive messages to and
  46.              from the collector ppppmmmmccccdddd(1), just like the other PMAPI
  47.              functions.
  48.  
  49.          3.  Full interoperability is supported for PCP 2.0, so new
  50.              PCP components will operate correctly with either new
  51.              or old PCP components.  For example, a PCP client that
  52.              connects to a PCP 1.x ppppmmmmccccdddd or attempts to process a
  53.              PCP archive created by a PCP 1.x ppppmmmmllllooooggggggggeeeerrrr will revert
  54.              to using the local PMNS.
  55.  
  56.              The following table describes the supported
  57.              interoperability between the client, ppppmmmmccccdddd(1) and PCP
  58.              archive log components of PCP 2.0 and PCP 1.x:
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.                                   - 2 -
  71.  
  72.  
  73.  
  74.               ___________________________________________________
  75.                                  PCP 1.x client   PCP 2.0 client
  76.               ______________________________________________________________________________________________________
  77.                PCP 1.x _p_m_c_d           yes              yes
  78.                PCP 1.x archive        yes              yes
  79.                PCP 2.0 _p_m_c_d           yes              yes
  80.                PCP 2.0 archive         no              yes
  81.               ___________________________________________________
  82.               ||||||
  83.  
  84.  
  85.  
  86.  
  87.                                ||||||||||||
  88.  
  89.  
  90.  
  91.  
  92.                                                 ||||||
  93.  
  94.  
  95.  
  96.  
  97.                                                                  ||||||
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.          4.  The protocols between a PMDA and ppppmmmmccccdddd(1) have also
  105.              changed, through a new version of the _l_i_b_p_c_p__p_m_d_a
  106.              library.
  107.  
  108.              The following table describes the supported
  109.              interoperability between the ppppmmmmccccdddd(1) and PMDA
  110.              components of PCP 2.0 and PCP 1.x:
  111.  
  112.         ________________________________________________________________
  113.                           PCP 1.x     PCP 1.x      PCP 2.0     PCP 2.0
  114.                         daemon PMDA   DSO PMDA   daemon PMDA   DSO PMDA
  115.         ________________________________________________________________________________________________________________________________
  116.          PCP 1.x _p_m_c_d       yes         yes          no           no
  117.          PCP 2.0 _p_m_c_d       yes          no          yes         yes
  118.         ________________________________________________________________
  119.         |||||
  120.  
  121.  
  122.  
  123.                       ||||||||||
  124.  
  125.  
  126.  
  127.                                     |||||
  128.  
  129.  
  130.  
  131.                                                |||||
  132.  
  133.  
  134.  
  135.                                                              |||||
  136.  
  137.  
  138.  
  139.                                                                         |||||
  140.  
  141.  
  142.  
  143.  
  144.  
  145.          5.  Product structural changes.
  146.  
  147.              The PCP product images have been re-arranged as
  148.              follows.
  149.  
  150.                 +o _p_c_p__e_o_e contains all of the pieces that are
  151.                   common to any successful PCP installation,
  152.                   particularly for a collector system, i.e. a place
  153.                   where ppppmmmmccccdddd is running.
  154.  
  155.                 +o _p_c_p__e_o_e will ship in IRIX 6.5 and as part of PCP
  156.                   2.0 for earlier IRIX releases.
  157.  
  158.                 +o _p_c_p__e_o_e._s_w._m_o_n_i_t_o_r includes the oooovvvviiiieeeewwww monitoring
  159.                   application (for monitoring the performance of
  160.                   ORIGIN systems, from SC4-PCPORIGIN) and does not
  161.                   require any PCP licenses.
  162.  
  163.                 +o _p_c_p._s_w._b_a_s_e provides the core PCP components that
  164.                   are outside _p_c_p__e_o_e.
  165.  
  166.                 +o _p_c_p._s_w._m_o_n_i_t_o_r provides all of the PCP client
  167.                   tools for monitoring performance.
  168.  
  169.                 +o The other _p_c_p subsystems provide optional PCP
  170.                   components.
  171.  
  172.          6.  PCP 2.0 introduces some new extensions to the PMAPI,
  173.              mostly to accommodate the distributed PMNS and some
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.                                   - 3 -
  186.  
  187.  
  188.  
  189.              underlying protocol changes to support enhanced
  190.              inter-operability.  The _l_i_b_p_c_p and _l_i_b_p_c_p__p_m_d_a
  191.              libraries have been updated to version sgi2.0.  The
  192.              older versions of these libraries are still supported
  193.              and may be installed from the _p_c_p._s_w._c_o_m_p_a_t subsystem
  194.              if required for older PMDAs or customer-developed PCP
  195.              applications.
  196.  
  197.              The API has also changed in some ways related to
  198.              symbol hiding and changes in function arguments.  The
  199.              xxxxllllaaaatttteeee____ppppmmmmaaaappppiiii script in the _p_c_p__g_i_f_t_s._s_w._m_i_g_r_a_t_e
  200.              subsystem may be used to automate the bulk of the
  201.              source code translation from the 1.x version to the
  202.              2.0 version of the PMAPI, i.e. from _l_i_b_p_c_p._s_o._1 and
  203.              _l_i_b_p_c_p__p_m_d_a._s_o._1 to _l_i_b_p_c_p._s_o._2 and _l_i_b_p_c_p__p_m_d_a._s_o._2.
  204.  
  205.          7.  In the transition from PCP 1.2 to PCP 1.3, the
  206.              _l_i_b_p_c_p__l_i_t_e library was removed and the functionality
  207.              replaced by the new PPPPMMMM____CCCCOOOONNNNTTTTEEEEXXXXTTTT____LLLLOOOOCCCCAAAALLLL option to
  208.              ppppmmmmNNNNeeeewwwwCCCCoooonnnntttteeeexxxxtttt(3) in _l_i_b_p_c_p.  The old _l_i_b_p_c_p__l_i_t_e
  209.              library is still available in the _p_c_p._s_w._c_o_m_p_a_t
  210.              subsystem.
  211.  
  212.          8.  ppppmmmmLLLLooooooookkkkuuuuppppNNNNaaaammmmeeee(3) now produces an extra error code,
  213.              PPPPMMMM____EEEERRRRRRRR____NNNNOOOONNNNLLLLEEEEAAAAFFFF which means that the given name refers
  214.              to a non-leaf node in the PMNS and so no PMID can be
  215.              returned.  Previously, if a non-leaf name was given
  216.              then PPPPMMMM____EEEERRRRRRRR____NNNNAAAAMMMMEEEE would be returned.  Now the error
  217.              PPPPMMMM____EEEERRRRRRRR____NNNNAAAAMMMMEEEE means only that the name does not exist in
  218.              the name space.
  219.  
  220.          9.  The function ppppmmmmGGGGeeeettttCCCChhhhiiiillllddddrrrreeeennnnSSSSttttaaaattttuuuussss(3) was added to the
  221.              PMAPI.  It was introduced mainly to satisfy a new need
  222.              of ppppmmmmcccchhhhaaaarrrrtttt(1).  As well as getting the names of all
  223.              the children nodes, ppppmmmmGGGGeeeettttCCCChhhhiiiillllddddrrrreeeennnnSSSSttttaaaattttuuuussss returns a
  224.              parallel array of the status of each node, indicating
  225.              if it is a leaf or non-leaf node.
  226.  
  227.         10.  A new (much smaller) format for PMDA help text files
  228.              has been implemented, with support in the _l_i_b_p_c_p__p_m_d_a
  229.              library and the nnnneeeewwwwhhhheeeellllpppp(1) utility.
  230.  
  231.         11.  A ----LLLL option was added to ppppmmmmdddduuuummmmpppplllloooogggg(1) to produce a
  232.              more verbose variant of ----llll and report all of the
  233.              details from a PCP archive label.
  234.  
  235.         12.  ppppmmmmllllooooggggggggeeeerrrr(1) uses the additional ppppmmmmccccdddd state change
  236.              information to embed "mark" records in PCP archives
  237.              when new PMDAs are started by ppppmmmmccccdddd.  During replay,
  238.              this prevents interpolation of values in the PCP
  239.              archive across the life of an old and a new instance
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.                                   - 4 -
  252.  
  253.  
  254.  
  255.              of the same PMDA.
  256.  
  257.         13.  The temporal index file (``.index'' suffix) is
  258.              optional when PCP archives are being replayed.
  259.  
  260.         14.  Changes to track the object format of the booted IRIX
  261.              kernel, briefly:
  262.  
  263.                 +o ``MACH'' tag key PCP binaries in the images to
  264.                   ensure installation of o32, n32 or n64 versions
  265.                   as appropriate, based upon the installation
  266.                   platform and the IRIX version.
  267.  
  268.                 +o Only one version of the ppppmmmmccccdddd binary will be
  269.                   installed, now in /_u_s_r/_e_t_c/_p_m_c_d.
  270.  
  271.                 +o A new ppppmmmmoooobbbbjjjjssssttttyyyylllleeee(1) command is used to determine
  272.                   the appropriate kernel object style at run time
  273.                   as required, e.g. when ppppmmmmccccdddd(1) is attaching a DSO
  274.                   PMDA.
  275.  
  276.        3.2  _C_o_l_l_e_c_t_o_r__C_h_a_n_g_e_s
  277.  
  278.        The following changes effect PMCD and the PMDAs that provide
  279.        the collection services.
  280.  
  281.        3.2.1  _G_e_n_e_r_a_l__C_o_l_l_e_c_t_o_r__C_h_a_n_g_e_s
  282.  
  283.          1.  ppppmmmmccccdddd(1) has been modified to support the distributed
  284.              name space.  This has meant the following changes:
  285.  
  286.                 +o ppppmmmmccccdddd(1) now loads the default name space on
  287.                   startup or an alternative name space if specified
  288.                   by ----nnnn.
  289.  
  290.                 +o On a SIGHUP signal it will reload the name space
  291.                   if it has been modified since the last load time.
  292.  
  293.                 +o ppppmmmmccccdddd(1) responds to name space PDU requests using
  294.                   its local name space.
  295.  
  296.          2.  ppppmmmmccccdddd(1) no longer requires a PCP collector license to
  297.              start, however connections will be refused for most
  298.              PCP clients unless the PCP collector license is
  299.              installed and valid.  Some clients (most notably
  300.              oooovvvviiiieeeewwww(1)) can connect to ppppmmmmccccdddd independent of any PCP
  301.              licenses.  To support this, the client-pmcd connection
  302.              protocols have been extended.
  303.  
  304.          3.  Support has been added for multiple protocol versions
  305.              for the client-pmcd IPC and the interaction between
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.                                   - 5 -
  318.  
  319.  
  320.  
  321.              ppppmmmmccccdddd and the PMDAs.
  322.  
  323.          4.  The logic used by ppppmmmmccccdddd for locating DSO PMDAs of the
  324.              correct object format has been reworked.
  325.  
  326.          5.  The diagnostic event tracing options of ppppmmmmccccdddd have been
  327.              extended to include an "unbuffered" mode where every
  328.              event is reported as it happens, as opposed to
  329.              buffering events in a ring buffer and only reporting
  330.              on errors and in response to explicit requests.
  331.  
  332.          6.  The distributed PMNS changes mean that ppppmmmmccccdddd must load
  333.              and export the PMNS in response to requests from
  334.              client applications.  ppppmmmmccccdddd's SIGHUP processing has
  335.              been extended to include reloading the PMNS if the
  336.              external PMNS file has been modified.
  337.  
  338.          7.  In concert with a change to ppppmmmmFFFFeeeettttcccchhhh in _l_i_b_p_c_p, ppppmmmmccccdddd is
  339.              now able to export out-of-band information about ppppmmmmccccdddd
  340.              state changes (specifically PMDA add, drop and
  341.              restart) back to client applications.
  342.  
  343.        3.2.2  _G_e_n_e_r_a_l__C_o_l_l_e_c_t_o_r__C_h_a_n_g_e_s__i_n__I_R_I_X__6_._5_._2
  344.  
  345.        To facilitate faster system reboots, the scheme used in
  346.        /_e_t_c/_i_n_i_t._d/_p_c_p has been revised to allow more of the ppppmmmmccccdddd
  347.        and ppppmmmmllllooooggggggggeeeerrrr launching to run in the background.
  348.  
  349.        In large system configurations, there may be some delay
  350.        between the completion of /_e_t_c/_i_n_i_t._d/_p_c_p and ppppmmmmccccdddd being
  351.        available.  The new application ppppmmmmccccdddd____wwwwaaaaiiiitttt(1) has been
  352.        provided for situations where scripts need to guard against
  353.        ppppmmmmccccdddd availability.
  354.  
  355.        3.2.3  _L_i_b_i_r_i_x_p_m_d_a__C_h_a_n_g_e_s__f_r_o_m__I_R_I_X__6_._5__t_o__I_R_I_X__6_._5_._1
  356.  
  357.        The following incidents were resolved for IRIX 6.5.1.
  358.  
  359.        588158  A section called "Enabling of Statistics Collection"
  360.                has been added to the lllliiiibbbbiiiirrrriiiixxxxppppmmmmddddaaaa(5) man page.
  361.  
  362.        603178  Extra diagnostic messages were added to log the
  363.                state changes of turning the xlv statistics
  364.                gathering on or off.
  365.  
  366.        3.2.4  _L_i_b_i_r_i_x_p_m_d_a__C_h_a_n_g_e_s__f_r_o_m__I_R_I_X__6_._5_._1__t_o__I_R_I_X__6_._5_._2
  367.  
  368.        The following incidents were resolved for IRIX 6.5.2.
  369.  
  370.        558773  Added metrics for the instantaneous disk queue
  371.                length and for the running sum of the disk queue
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.                                   - 6 -
  384.  
  385.  
  386.  
  387.                lengths.
  388.  
  389.        3.3  _M_o_n_i_t_o_r__C_h_a_n_g_e_s
  390.  
  391.        The major additions and changes for the performance
  392.        visualization and analysis tools are described below.
  393.  
  394.          1.  Monitor applications no longer use the local default
  395.              name space to get PMIDs for metric names unless the
  396.              name space file is explicitly given as a ----nnnn option or
  397.              the target ppppmmmmccccdddd, specified by ----hhhh, is a lower revision
  398.              than PCP 2.0.  Monitor applications use the
  399.              distributed name space by sending PDU requests to
  400.              ppppmmmmccccdddd.
  401.  
  402.          2.  To convert an existing user-written monitor
  403.              application to use the distributed name space, the
  404.              following must be done:
  405.  
  406.                 +o Only call ppppmmmmLLLLooooaaaaddddNNNNaaaammmmeeeeSSSSppppaaaacccceeee(3) in the case of being
  407.                   given a ----nnnn option to specify a particular name
  408.                   space file.  If one only wants to use the
  409.                   distributed name space then the call to
  410.                   ppppmmmmLLLLooooaaaaddddNNNNaaaammmmeeeeSSSSppppaaaacccceeee(3) can be deleted altogether.  As
  411.                   soon as ppppmmmmLLLLooooaaaaddddNNNNaaaammmmeeeeSSSSppppaaaacccceeee(3) is called, the
  412.                   application is in local name space mode.
  413.  
  414.                 +o All calls to the PMAPI name space functions must
  415.                   be made in a current PMAPI context.  Previously,
  416.                   since a context was not used to service name
  417.                   space functions, it was possible to call these
  418.                   functions before any new context was created.
  419.                   Now, if there is no current PMAPI context and
  420.                   ppppmmmmLLLLooooaaaaddddNNNNaaaammmmeeeeSSSSppppaaaacccceeee(3) has not previously been called
  421.                   when a name space function is called an error
  422.                   code will be returned.
  423.  
  424.                 +o The calls to the PMAPI name space functions (in
  425.                   distributed mode) will take longer to execute (as
  426.                   they must send/receive a PDU to/from a remote
  427.                   ppppmmmmccccdddd).  This means that the name space calls
  428.                   should not be made unnecessarily.
  429.  
  430.                 +o All name space calls should be tested for
  431.                   failure.  This was, of course, always the case,
  432.                   but previously there was more chance that one
  433.                   could get away without testing some calls for
  434.                   failure. However, now, every call could have some
  435.                   failure due to problems with sending or receiving
  436.                   a PDU.
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.                                   - 7 -
  450.  
  451.  
  452.  
  453.          3.  The oooovvvviiiieeeewwww(1) application for monitoring Origin 200 and
  454.              Origin 2000 systems has migrated from the SC4-
  455.              PCPORIGIN product and is now included in the
  456.              _p_c_p__e_o_e._s_w._m_o_n_i_t_o_r subsystem.  This application is
  457.              unlicensed and will operate with an unlicensed
  458.              ppppmmmmccccdddd(1).
  459.  
  460.          4.  Many of the GUI PCP tools have been integrated into
  461.              the IRIX Interactive Desktop environment, including
  462.              launch by icon, drag-n-drop behavior for hosts or
  463.              archives dropped onto PCP tools and a new ppppmmmmrrrruuuunnnn(1)
  464.              command to support optional command line arguments for
  465.              PCP tools launched from the desktop.
  466.  
  467.          5.  A PPPPeeeerrrrffffTTTToooooooollllssss page in the Icon Catalog has been created
  468.              for launching PCP tools.
  469.  
  470.          6.  The handling of error messages for both GUI and
  471.              command-line invocations of most tools has been
  472.              unified and made more consistent.
  473.  
  474.          7.  The ppppmmmmttttiiiimmmmeeee(1) application that provides time control
  475.              services to other PCP tools has been enhanced in a
  476.              number of ways:
  477.  
  478.                 +o A new Archive Time Bounds dialog (available only
  479.                   in archive mode) allows time window bounds to be
  480.                   constrained or expanded at run-time (particularly
  481.                   useful when replaying archives that are still
  482.                   growing).
  483.  
  484.                 +o Extensions to the ppppmmmmttttiiiimmmmeeee client protocol to allow
  485.                   clients to force VCR state changes and alter the
  486.                   time window bounds.
  487.  
  488.                 +o The ppppmmmmttttiiiimmmmeeee protocol is nnnnooootttt backwards compatible
  489.                   with the PCP 1.x implementation, but all clients
  490.                   of ppppmmmmttttiiiimmmmeeee are re-released with the images on the
  491.                   PCP 2.0 CD and both ppppmmmmttttiiiimmmmeeee and its clients
  492.                   execute on the same system.
  493.  
  494.          8.  The ppppmmmmkkkkssssttttaaaatttt(1) command has been restructured in the
  495.              wake of _l_i_b_p_c_p__l_i_t_e's demise, and in particular a new
  496.              ----LLLL option supports stand alone use without ppppmmmmccccdddd(1).
  497.  
  498.        3.4  _F_e_a_t_u_r_e_s__R_e_m_o_v_e_d__o_r__D_e_p_r_e_c_a_t_e_d
  499.  
  500.        In PCP 2.0, the following features from earlier PCP versions
  501.        have been removed.
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.                                   - 8 -
  516.  
  517.  
  518.  
  519.          1.  The original intent in the Performance Co-Pilot
  520.              framework was to support seamless VCR-replay between a
  521.              current ``live'' source and a recently created archive
  522.              source.
  523.  
  524.              In practice, the semantic and operational difficulties
  525.              associated with transitions between ``live'' and
  526.              ``archive'' modes are so significant that the feature
  527.              has been abandoned.
  528.  
  529.              Earlier PCP releases included a ``stubbed-out''
  530.              application ppppmmmmvvvvccccrrrr(1) that did not really do anything
  531.              and assorted infrastructure ``hooks''.  These have
  532.              been removed.
  533.  
  534.          2.  _l_i_b_p_c_p__l_i_t_e._s_o - replaced by PPPPMMMM____CCCCOOOONNNNTTTTEEEEXXXXTTTT____LLLLOOOOCCCCAAAALLLL The
  535.              standalone (without ppppmmmmccccdddd) library _l_i_b_p_c_p__l_i_t_e._s_o has
  536.              been replaced by the PPPPMMMM____CCCCOOOONNNNTTTTEEEEXXXXTTTT____LLLLOOOOCCCCAAAALLLL option to the
  537.              ppppmmmmNNNNeeeewwwwCCCCoooonnnntttteeeexxxxtttt(3) routine.
  538.  
  539.        The following features and services are supported in PCP
  540.        2.0, but the intention is to remove them in a future PCP
  541.        version.
  542.  
  543.          1.  ASCII mode PDUs and the PPPPDDDDUUUU____AAAASSSSCCCCIIIIIIII argument to
  544.              ppppmmmmNNNNeeeewwwwCCCCoooonnnntttteeeexxxxtttt(3).  To the best of our knowledge,
  545.              nothing but the ``toy'' demonstration PMDA news agent
  546.              has ever used this. The current PCP libraries (in
  547.              particular _l_i_b_p_c_p__p_m_d_a and _l_i_b_p_c_p__t_r_a_c_e) make building
  548.              a real PMDA less effort than fighting with the ACSII
  549.              PDUs in a sssshhhh(1) script.
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573.  
  574.  
  575.  
  576.  
  577.  
  578.